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Preface 


This document is an after action report summarizing all activities completed up to July 31, 
2000 on the Strong Angel project. The report also identifies the tasks that remain and must be 
completed prior to project completion. All data and results in this report are preliminary and 
require further analysis. Analysis will continue as more data are acquired from the remaining 
tasks. A final report will be generated and distributed at the conclusion of the Strong Angel 
project. 
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Executive Summary 


With the construction of the International Space Station and the resulting longer mission 
durations it has become necessary to expand the on-orbit medical capabilities. The Medical 
Operations Branch (MOB), at Johnson Space Center (JSC), has taken responsibility for 
expanding these capabilities under the Clinical Care Capability Development Project 
(CCCDP). One element of CCCDP is to enhance the critical care monitoring capabilities. 

Medical Operations was invited to participate in exercise “Strong Angel”, a civilian/military 
humanitarian relief effort. Strong Angel was a component in the “Rim of the Pacific” 
(RIMPAC) 2000 exercise that took place in Hawaii June 6, to June 18. Medical Operations 
used this opportunity to evaluate the ability of commercial portable critical care monitors to 
provide real-time patient data from a remote environment to a clinician using a satellite 
communication network (SCN). This communication scenario was analogous to ISS 
conditions. The objectives of Medical Operations were to: 

• Determine state of the art and evaluate critical care monitors 

• Develop collaborative relationships and information exchange with medical device vendors 

• Identify current trends in critical care monitoring clinical communications standards 

• Determine future trends and technologies of critical care monitors 

• Define requirements for space mission critical care monitoring capability 

• Validate procedures for treating a critically injured astronaut aboard the ISS 

Medical Operations performed a market search on commercially available critical care 
monitors and acquired several monitors for evaluation purposes. Three of the five monitors 
received satisfied all of the original functionality requirements including the ability to send 
medical data across a TCP/IP network. These three monitors were then evaluated using a 
satellite communications simulator to determine their ability to support TCP/IP data transfer 
of simulated patient data with various satellite latencies and error rates. Critical care monitors 
able to operate with predetermined latencies and error rates were used in the Strong Angel 
field trials in Hawaii. 

Once in Hawaii the monitors were tested through a real SCN in conjunction with simulated 
medical scenarios. The simulated medical data used in all the evaluations were generated 
using calibrated biomedical test instruments. Additional evaluations included evaluating the 
monitor’s user interface, usability of the monitor’s remote interface, its clinical functionality 
in harsh environments, its engineering design with respect to potential use on ISS, and 
validating the procedures for treating a critically injured astronaut aboard the ISS. 

Overall, all monitors and equipment performed well. Notable achievements to date include 1) 
a demonstration of real time remote diagnostics and treatment using commercial-off-the-shelf 
critical care monitors. Moreover, this demonstration was implemented using the public 
Internet; 2) development and implementation of clinical scenarios for hip pocket procedure 
development; and 3) a detailed survey of the state-of the-art in critical care monitor 
technology. 
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This project, even though it is not complete, is proving to be very successful. The evaluations 
have provided valuable data that will be used in enhancing the on-orbit critical care 
capabilities. At the time of writing evaluation data are still being acquired. A final report, 
including a complete set of requirements for ISS critical care monitoring capabilities, will be 
completed at the conclusion of the this project. This report will be shared with all 
participating vendors. 
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Introduction 


The NASA critical path road map identifies “trauma and acute medical problems” as a clinical 
capability risk category ( http://criticalpath.isc.nasa.gov) . Specific risks include major trauma, 
organ laceration or contusion, hemoperitoneum, pulmonary failure, pneumo- and hemothorax, 
bum, open bone fracture, blunt head trauma, and penetrating injury. Mitigation of these risks 
includes the capability for critical care monitoring. Currently, the International Space Station 
(ISS) Crew Health Care System (CHeCS) does not provide such a capability. The Clinical 
Space Medicine Strategic Planning Forum (4/8/97), sponsored by NASA Medical Operations, 
identified the development of trauma care capabilities as one of the top priorities for space 
medicine. The Clinical Care Capability Development Project (CCCDP) subsequently 
undertook the task to address this need. 

In January 2000, Johnson Space Center’s (JSC) Medical Operations Branch (MOB) was 
invited to participate in the RIMPAC 2000/Strong Angel exercise in the Hawaiian Islands. 

This exercise was conducted on 6-18 June 2000, and involved seven nations and several 
public health and disaster-response organizations. A key component of this exercise was the 
establishment of a 300-person mock refugee camp to simulate mass dislocation due to conflict 
or natural disaster. This refugee camp was located on the big island of Hawaii. 

(See Appendix A for a listing of URLs that will provide additional information) 

Both a wireless network (Refugee camp to CMOC only) and a satellite system provided by 
ECU and Medweb connected the refugee camp to the East Carolina University School of 
Medicine (ECU). The satellite system was the primary method of communication and was 
configured to support a TCP/IP network. Many organizations used the network to send real- 
time Internet protocol (IP) video, biosensor data through telemetry, store/forward data from 
clinical telemedicine sessions, and real-time critical care monitoring data. One of Strong 
Angel’s objectives was to build a nomadic computing network matrix that would link together 
the seven countries participating in this exercise through the ECU bridge. 

Medical Operations personnel used this exercise to evaluate critical care monitors in a real- 
world telemedicine setting analogous to ISS conditions and to simulate potential ISS medical 
scenarios. The simulated patient was located in Hawaii, whereas, the medical consultants 
(NASA flight surgeons) were located in Houston. There were additional experts located in 
Star City, Russia, Toronto, Canada, and Philadelphia, Pennsylvania. This exercise afforded 
the CCCDP a unique opportunity to work with commercial vendors and evaluate their leading- 
edge technology and to evaluate the feasibility of treating an astronaut aboard the ISS using 
limited medical resources. These opportunities were consistent with the CCCDP critical path 
towards enhancing long-term Advanced Life Support System (ALS) capabilities. 




CCCDP Strong Angel activities were subdivided into four separate phases: 


Phase 1 

In-House Testing 

Houston 

1 March, 2000 

Phase 2 

Remote Monitoring/TDRSS Simulator Testing 

Houston 

20 April, 2000 

Phase 3 

Operational Deployment 

Hawaii 

8 June, 2000 

Phase 4 

Post-Deployment 

Houston 

19 June, 2000 


At this writing, only Phase 3 has been completed. Phase 1 and 2 activities were limited to 
configuration and data transmission capability testing to determine which monitors should be 
deployed during Phase 3. Activities are still ongoing for Phases 1 , 2, and 4. This report will 
describe the accomplishments to date. A final report will be issued when all phases are 
completed. 
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Phase 1 - In-House Testing 


Phase 1 involved a trade study researching the portable critical care monitor industry, 
acquiring equipment and becoming familiar with the systems. Phase 1 plans also called for 
usability and human factor tests on the various systems, but due to time constraints, these tests 
are planned for the Post Deployment phase. 

The trade study consisted of consulting with industry contacts, consulting with the MDB 
Information Network, reviewing publications written by the Emergency Care Research 
Institute (ECRI), and contacting the vendors of critical care monitors. After performing a 
market trade study, eight vendors were identified as having products that might meet the 
requirements identified in the Strong Angel Project Plan (refer to Appendix B). These vendors 
were contacted to gauge their interest in supporting the project and, of these, six expressed 
interest in participating and supplying equipment for testing. These six vendors agreed to loan 
monitors and their appropriate accessory equipment to Medical Operations/CCCDP for a one 
year period. However, only five of the vendors were able to deliver equipment within the time 
frame needed to support testing before actual deployment. At the time of writing one 
company is still working on delivering equipment to Medical Operations. 

Vendors provided detailed technical information regarding their products and several sent 
engineering staff to support the initial monitor setup and familiarization. After familiarization 
with the equipment, review of the supplied documentation, and performing initial tests with 
the monitors, only three met the criteria for deployment to Hawaii. The main factor for 
determining whether a monitor went to Hawaii was its capability to deliver medical data 
across a TCP/IP network and the ability to view these data at a remote site. Table 1 
summarizes the vendor transactions. 


Table 1 : Matrix describing vendor transactions 


Vendor 

Monitor(s) 

Responded 
positively to 
initial invitation 

Provided 

monitor(s) 

before 

deployment to 
Hawaii 

Monitor(s) 
actually 
deployed in 
Hawaii 


M3 

Yes 

Yes 

No 

GE-Marquette 

Ml 

No 

No 

No 

IBBSMBMillM 

Ultraview 1050 

Yes 

Yes 

Yes 

Datex-Ohmeda 

CS3 

Yes 

Yes 

Yes 

Datascope 

Expert or 
Passport 

Yes 

Yes 

No 

Critikon 


No 

No 

No 

Protocol 

Propaq CS or 
Propaq 

Yes 

No 

No 

Siemens 

SC7000 

Yes 

Yes 

Yes 
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Phase 2 - Remote Monitoring/TDRSS Simulator Testing 


Phase 2 was comprised of the following tasks: 

1 . Configuring the critical care monitors for networking across a TCP/IP network 

2. Verifying that communications were valid 

3. Testing the monitors on a simulated satellite network 

4. Developing a physiologic simulator test system for use in Hawaii 

5. Developing several medical scenarios for use during the deployment phase. 

Three of the five monitors sent to Medical Operations were able to satisfactorily complete the 
first three tasks. These monitors were tested using a communications link simulator system 
located in the Building 44 Avionics Laboratory at JSC 1 . However, due to time constraints, 
only two of the monitors were actually tested with this simulated link. 

Equipment 

Communications Link Simulator System 

The Avionics group at JSC developed the communications link simulator to imitate the 
communications link (KU-band) between Mission Control Center (MCC) and the Space 
Shuttle or the International Space Station (ISS). The system consists of two local area 
networks (LAN) that are connected to each other through the TDRSS satellite simulator or 
“delay box.” These LANs represent the MCC (ground-side) and either the Shuttle or the 
ISS (flight side). Each LAN has several workstations, a hub, and a router containing an 
orbital communications adapter (OCA) communications card that interfaces directly to the 
delay box. The delay box simulates the delay introduced when a communications signal 
travels through a satellite (i.e., a TDRSS satellite). The delay box has the capability to 
simulate various signal delays (0 sec., 0.55 sec., 0.80 sec., and infinite) and various data bit 
error rates (0, 1/100000, 1/1000, and 3/1000 bit errors per data bits). 

Critical Care Monitors 

Monitors tested during this phase were required to connect to a TCP/IP network. Three 
monitors satisfied this requirement, the CS/3 (Datex-Ohmeda, Tewksbury, MA); SC7000 
(Siemens Medical Systems, Inc., Danvers, MA); and the Ultraview 1050 (Spacelabs 
Medical, Inc., Redmond, WA). These monitors lacked the ability to connect directly to a 
TCP/IP network, but used their own proprietary network protocol. Thus, all monitors 
required the use of a gateway running proprietary software that would translate their 
protocol into TCP/IP. Two of the monitors used a gateway provided by Wyle Laboratories 
(Panasonic Toughbook) that was then configured with the appropriate software provided 
by the vendors. The third monitor used a gateway provided by the vendor. 


1 Contacts for this lab are Brett Parrish and Steven Schadelbauer. 
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Physiologic Simulators 

To test each monitor, physiologic simulators were used to create the following signals: 

• electrocardiogram - ECG, 

• pulse oximetry - SpC> 2 , 

• noninvasive and invasive blood pressures - NIBP and IBP, 

• temperature 

• respiration 

Consultant Workstation 

The computer workstation, located at the primary consultant station in Houston, was an 
Intel Pentium II based computer. It was running the Windows ’95 operating system. 
Internet Explorer 5.0 and Siemens’ WinView client software packages were both installed. 
Internet Explorer was used to view data sent by Datex-Ohmeda’s CS/3 and Spacelab’s 
Ultraview 1050. WinView client was used only to view data sent by Siemens’ SC7000 
monitor. 

The secondary workstations were also Intel Pentium II based machines running either 
Windows ’98 or Windows 2000. All used Internet Explorer 5.0 to view the transmitted 
monitoring data. 

Test Setup and Protocol 

For each test in the Building 44 Avionics Lab, one monitor was connected to its respective 
gateway. The gateway was then connected to the flight-side LAN via the flight-side hub. A 
multipurpose workstation running Windows NT and Internet Explorer 5 was plugged into the 
ground-side LAN via the ground-side hub. Before testing began, it was ensured that both the 
multipurpose workstation and the monitor’s gateway could ‘ping’ each other, verifying a good 
network connection. Once a good connection was verified, Internet Explorer was run on the 
multipurpose workstation and used to acquire and display the real-time data coming from the 
monitor being tested. Each monitor tested displayed four waveforms, two ECG, pulse 
oximeter, and respiration waveforms as well as NIBP, temperature, pulse rate, respiratory rate, 
and oxygen saturation. On the workstation end, the four waveforms and all numerical data 
were displayed (Figure 1 ). 

Each monitoring system underwent a series of four tests. The first test was conducted to 
determine how the monitoring system reacted to a time delay in the communications link. 
Initially, the delay box was set to no delay and no data bit errors. Once the data displayed on 
the workstation were stable (the system was allowed to run for approximately 60 sec.), the 
settings on the delay box were changed. For the first test only, the delay times were changed 
(they were increased to 0.55 and then to 0.80). Each time they were changed, time was given 
to allow the systems to stabilize, and then the effect on the system was noted. 

The second test was designed to determine how the monitoring system reacted to errors in the 
data stream. For this test, the delay time was set to a constant 0.55 sec., as this was the same 
delay that the systems would encounter in Hawaii. The data bit error rate was increased from 
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0 to 3/1000 incrementally. Each time the rate was increased, time was allowed for the system 
to stabilize. Notes were taken on how the error rates affected the system. 

The third test determined how the monitoring system would react if a loss of signal (LOS) was 
experienced. This was done by physically disconnecting one of the communication cables 
from the delay box thereby severing all communications. 

The fourth test determined how the monitoring system would react if individual components 
of the communications signal were lost independently of one another. This was done by 
bypassing the delay box with a set of “breakout cables.” The set consisted of four cables 
carrying the following signals: TxD (data down), TxD clock, RxD (data up), and RxD clock. 
Each signal was disconnected and the system’s response was noted. 




Spacelabs System 


Also used for Datex 
system 


Toughbook 

Gateway 

3COM IP: 192.168.50.99 
Mask:255.255.255.0 
Default:! 92. 1 68.50. 1 0 


Other 

Workstations 


Spacelabs 

IP: 192.168.50.100 
Mask:255. 255.255.0 
Default:! 92.1 68.50. 1 0 


Datex-Ohmeda 

Monitor 


HUB 


Datex-Ohmeda 

Gateway 

IP: 192.168.50.99 
Mask:255. 255.255.0 
Default:! 92.1 68.50.10 


Datex System 


Multipurpose 

Workstation 

IP: 192.168.10.98 
Mask:255.255.255.0 
Default: 192. 168. 10. 10 



Other 

Workstations 



• Figure 1 Diagram of setup for testing equipment with satellite communications simulator. 
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Phase Two Results 

SpaceLabs Ultraview 1050: 

The SpaceLabs Ultraview 1050 monitor worked well with delays between 0 and 0.80 
seconds. However, the time it took for the web browser to load data increased 
proportionally to the increase in delay. Moreover, the data being displayed on the 
workstation increasingly lagged the monitor sending the data, resulting in a phase delay 
between the simulated patient and the remote patient monitor (workstation). This delay 
varied from 7 sec. with no delay introduced in the link, to about 15 sec. with 0.8 sec. 
delay. These were expected results. 

When data bit errors were introduced to the system, data were lost. The data became 
patchy (missed data) when the data bit error rate was set to 1/100000, the lowest setting on 
the box. This setting is the worst-case specification for the TDRSS satellite system. 
Although the data were patchy, the system recovered and continued to display data. 
Occasionally, one waveform was lost. When the rate was increased to 1/1000, the data 
became even more patchy and occasionally all data were lost. Both waveform and 
numeric data were effected. Occasionally the web browser recovered from this, but more 
often than not it required restarting. When the rate was increased to 3/1000, data were 
displayed for a few seconds before it completely crashed - no data were displayed. The 
web page was restarted, but it never was able to reconnect to the monitor/gateway and 
resume operation. A 3/1000 data bit error rate corresponds to a 15 to 20% loss of data. 

Overall, when there was data loss, the waveform data were compromised more than the 
numeric data. 

Loss of signal (LOS) was simulated for 45 seconds. During this test, the workstation 
receiving the data went blank after 7 seconds and the gateway went blank after 12 seconds. 
The gateway response was not expected. Once the signal was reestablished, the gateway 
displayed data again, but the workstation never recovered. The web browser, Internet 
Explorer, needed to be restarted. 

Loss of individual signal lines was also simulated for 45 seconds. The results were similar 
to the LOS test. The one difference was that the gateway did not lose data. The data were 
being displayed continuously. Data was lost on the gateway only when all four signals 
were disconnected simultaneously. 


Datex-Ohmeda CS3: 

The Datex-Ohmeda monitor was initially tested with no delay in the communications link. 
There were no anomalies in the data being displayed at the workstation. Once a 0.55 
second delay was introduced to the system, some data at the workstation were lost. Two 
of the waveforms, pulse oximeter and respiration, and some of the numeric data were 
dropped. When the delay was increased to 0.80 seconds, only the two ECG waveforms 
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appeared on the display and, at times some of their data were lost resulting in patchy 
waveforms. The numeric data were lost at times too. 

When data bit errors were introduced to the system, the data being displayed on the 
workstation became patchy with more data dropping out, both waveform and numeric. 
When the data bit error rate was set to 1/100000, one of the waveforms was lost and the 
others had sections of missing data. A couple of the numerical data points were lost. 

When the error rate was set to 1/1000, the workstation lost all data. It was intermittent for 
about 10 seconds, and then went blank. When the 3/1000 rate was dialed in, no data were 
displayed on the workstation. 

Loss of signal (LOS) was simulated for 45 seconds. During this test, the workstation 
receiving the data went blank after a few seconds. Once the connection was reestablished, 
the web browser at the workstation never recovered. It was only after it was restarted that 
it began displaying data again. 

When simulating the loss of individual signal lines each loss was done for 45 seconds. 
When TxD (data down), TxD clock lines were disconnected, the results were similar to the 
LOS test. However, when the other lines, RxD (data up), and RxD clock, were 
disconnected there was no noticeable effect. During this testing phase the CS3 monitor 
did exhibit a few anomalies. The display would flicker occasionally and once went 
completely blank. It was noticed that when this happened, the alarm on the CS3 did not 
sound normal but made a sound similar to a metronome (a ticking sound instead of the 
normal alarm tone). The Datex-Ohmeda representative concluded that the problem was 
probably a loose connector on the display panel. The CS3 monitor had been used 
previously on KC-135 flights and the strip-chart recorder assembly had been removed 
from the unit and a VGA cable installed to provide VGA video output. This may have 
compromised the integrity of the system. 


Siemens CS 7000 

The Siemens monitor was not tested in the avionics lab using the above protocol. It was 
received on 26 May, leaving only 7 days until the shipping deadline for deployment to 
Hawaii. The system was tested using the CCCDP LAN and remote Internet accesses. 
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Summary 

Overall, all monitors and equipment worked well through the test link. The testing provided 
good feedback on the expected behavior of the monitors under various communications link 
conditions. This proved to be useful information for troubleshooting the systems in Hawaii. 
See Table 2. 


Monitors 

Delay time 

LOS 

Bit error rate 

Loss of Signal lines 

Os 

0.55s 

0.8s 

45s 

0 

1/100000 

1/1000 

3/1000 

TxD 

TxD elk 

RxD 

RxD elk 

CS/3 

X 

M 

M 

- 

X 

M 

- 

- 

- 

- 

X 

X 

Ultraview 1050 

X 

X 

X 

- 

X 

M 

M 

- 

- 

- 

- 

- 

SC7000 

Not Tested 

Not Tested 

Not Tested 

Not Tested 


Key: 


X 

M 


Good; no data loss 
Marginal; some data loss 
Transmission completely lost 


• T able 2 Summary of monitor performance in satellite communicaitons test 
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Physiologic Simulator System Development 

Physiologic input signals (electrocardiogram - ECG, pulse oximetry - Sp02, non-invasive 
blood pressure - NIBP, invasive blood pressure - IBP, temperature, and respiration) were 
generated using an array of medical equipment calibrators that were controlled by a 
computer. The calibrators were loaned and then subsequently purchased from Bio-Tek, 
Incorporated and consisted of the following: 

• LionHeart 3 - a lightweight, portable patient simulator that provides ECG (3, 5, or 12 
lead), invasive blood pressure (static or dynamic), respiration, and temperature outputs. 
It also provides multiple heart arrhythmias (over 30 types), artifacts, and other 
simulation functions (such as S-T segments, pacing, etc.). It also provides a variety of 
signals (sine, square, triangle waves) that can be used to verify the performance of 
ECG monitors. 

• Index 2 - a pulse oximeter tester that provides the ability to simulate the blood oxygen 
conditions of a patient and presents the signal to a pulse oximeter’s finger sensor. It 
provides oxygen saturation levels from 35 to 100 % and pulse rates from 25 to 250 
beats per minute. In addition, abnormal conditions in 02 sat and pulse rate caused by 
physiologic conditions can be generated through pre-programmed simulations. It also 
provides the ability to electrically verify pulse oximeter probe diodes, LEDs, and wire 
continuity. Also, since different R-curves can be programmed into the simulator, it 
can be used with any pulse oximeter on the market. 

• BP-PUMP - a non-invasive blood pressure monitor tester that provides dynamic blood 
pressure simulations, static calibration, automated leak testing, and high/low pressure 
release verification. The simulations provided include normal pressures and pulse 
volumes; those produced by abnormal physical conditions, and motion artifacts. It 
contains an internal cuff that can be used instead of the original BP monitors cuff to 
eliminate the variability of cuff volume. 

The simulators can be used independently to test and calibrate various medical devices or 
to train medical personnel in recognition and interpretation of physiologic signals. The 
calibration of each simulator can be traced directly or indirectly to the U.S. National 
Institute of Standards and Technology (NIST), and Bio-Tek’s calibration program meets 
the requirements of the U.S. FDA’s Good Manufacturing Practices (GMP), ISO 9001, and 
M1L-STD-45662A. Because of the highly accurate nature of the physiologic signals, the 
simulators will provide for thorough equipment evaluation, system development and 
prototype validation, as well as providing a full range of patient pathology simulations. 

For the Strong Angel project, the simulator system provided the basis for evaluating and 
comparing the critical care monitors. Medical scenarios relevant to space operations risk 
data were designed based on the equipment’s ability to simulate the physiologic signals. 

As the ‘patient’ progressed through the scenario, the signals changed appropriately. 
Computer control of the simulators was accomplished using Bio-Tek’s OTIS software 
application loaded onto a PC. The simulators were connected to the computer via an 
electronic switcher (Smart Switch, model 232XS5 manufactured by B&B Electronics). 
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The OTIS software contained all of the device commands for each simulator and provided 
a programming environment to automate sending the commands to each device. 

The instruments used for the medical scenarios were primarily designed for the purpose of 
calibrating medical monitoring devices, not to simulate medical scenarios as in Strong 
Angel. Therefore, there were limitations to the fidelity of the medical scenarios associated 
with the off-nominal use of the simulators. Specifically, the following observations from 
the development period should be noted: 

• The interfaces of the different simulators (LionHeart 3, Index 2, BP Pump) operate at 
different baud rates and require different inter-character delays. This required 
additional programming and switching time from device to device. Device settings for 
the simulations were: 

o LionHeart 3 - 9600 baud, 100 msec delay 
o Index 2 - 9600 baud, no delay 
o BP-PUMP - 2400 baud, 1000 msec delay 
o Smart Switch - 9600 baud, no delay 

• The heart rate (HR) is not adjustable on second and third degree heart block or pacing 
simulations. More flexibility in setting HR is desirable. 

• Although the ECG and IBP signals coming from the LionHeart 3 are synchronized, the 
heart rate pulse signal for SpC >2 generated by the Index 2 cannot be synchronized with 
the LionHeart 3. The ability to synchronize the SpC >2 signal with the ECG/BP signals 
would enhance the capability to produce high fidelity patient simulations. 

• The IBP levels provided by the LionHeart 3 are limited and do not correspond to all 
the levels available from the BP-PUMP. It is desirable to have the NIBP and IBP 
values agree during the simulations. 

• The Index 2 seemed especially sluggish in accepting commands from the computer. 
Usually a five-second delay after sending the command was required to allow the unit 
enough time to accept the command. Changing the baud rate on the Index 2 to lower 
settings did not appear to make a difference. 

• The BP-PUMP settings could not be changed if the monitor was taking an NIBP 
measurement at the time a command was sent. It is desirable to implement a command 
memory buffer in BP-PUMP to accept commands while the unit is performing a 
measurement. For these simulations a user message instructing the operator to check 
for NIBP measurement. However, this still requires the simulation coordinator be 
aware of the monitor’s NIBP measurement cycle. 

• It is desirable to have built-in defibrillation and CPR rhythm simulations in the 
LionHeart 3. For these simulations, a defibrillation pulse was roughly approximated 
with a square wave, 0.125 Hz from the LionHeart 3. A CPR rhythm would facilitate 
the simulation of many medical scenarios that might be encountered on ISS. The 
OTIS program editing capability is very awkward. The vendor has stated that a newer 
version will correct some of the weaker aspects of the program noted below: 

- Program lines cannot be selected for cut, paste, or delete anywhere on the 
line. The cursor must be positioned directly over the check item number. 
However, it does allow multiple lines to be selected. 
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Editing is slower as the program gets longer because it takes more time to 
paste lines and renumber. For the OTIS simulation program used in Hawaii 
(which was 328 lines long), the paste operation took 5 to 6 seconds on a 
486 PC. 

Cut and paste in OTIS was limited to approximately 10 program lines. If 
more lines were selected, the lines would not necessarily be pasted 
contiguously. 
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Phase III - Operational Deployment 


Phase three consisted of deploying all qualified monitors and their support equipment to 
Hawaii, testing the monitors using detailed patient scenarios, evaluating the monitors, and 
evaluating the feasibility of treating a critically injured astronaut aboard the ISS. Two 
Advanced Projects (AP) personnel traveled to Kailua-Kona, Hawaii June 8-18 2000. 
Approximately 400 lbs. of equipment (three critical care monitors and support equipment) was 
shipped to the Pohakaloa Training Center, a U.S. Marine facility on the Big Island, via UPS 2- 
Day air. 

Pre-Deployment Check-Out 

Prior to set up at the Strong Angel site, the monitors were set-up for a pre-deployment 
checkout and tested along with the ECU equipment at a facility located 20 miles from the site. 
During the pre-deployment checkout, CCCDP personnel set up their equipment facing into the 
sun to evaluate the performance of the monitors in direct sunlight. The only monitor that 
could be seen (able to view the data displayed on the monitor) was the SpaceLabs’ Ultraview 
1050. All other monitors, including computers, were impossible or very difficult to view. 
Other than difficulty viewing the monitors in the sunlight the equipment performed nominally. 
This opportunity was used to pre-configure and make last minute changes to the equipment 
and to verify the set-up and placement of equipment before transporting to the work site. 

This checkout also provided an opportunity to show the equipment to the other organizations 
that were involved in the Strong Angel exercise (American Red Cross, DARPA, Unicef, U.S. 
Navy, U.S. Marines, and the United Nations). 


Strong Angel Exercise Site 

The Strong Angel site was located just outside of Waimea, HI (this was about 30 minutes from 
AP personnel’s hotel). The Command Missions Operations Center (CMOC) was about 0.5 
miles from the main road at mile marker two and the refugee camp was located about three 
miles beyond the CMOC just at the base of Puu Paa, the central landmark in this volcanic ash 
field. (See figures 2 and 3) 
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Figure 2: Northwest Corner of the big island of Hawaii 
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Figure 3: Detail of CMOC and refugee camp 
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The CMOC and refugee camp consisted of 78 large green military canvas tents without 
flooring. Due to road conditions, no civilian vehicles were allowed past the CMOC to go to 
the refugee camp without prior approval. The only transportation to the refugee camp was by 
military transport vehicles: the high-mobility multipurpose wheeled vehicle (HMMWV) or 5- 
ton flatbed trucks. The conditions were very dirty, with an extremely fine dust, and wind. 
During the operation, gale force winds blew down tents and other facilities including 
communications equipment. Weather conditions throughout the deployment were cool with 
low humidity and rain on one occasion. During the day the temperature inside the experiment 
tent was approximately 90°F with night temperatures in the high 50’s. All AP equipment was 
located in the medical tent somewhat sheltered from the elements - although not completely. 
Volcanic dust, driven by the strong winds, required that equipment be covered with plastic to 
prevent dust from getting on/in equipment. When personnel left for breaks all equipment was 
covered with a large tarp. (See Figures 4 to 6) 



Figure 4 : Picture taken at CMOC site (note the windy/dusty conditions) 



Figure 5: View of refugee camp from the top of Puu Paa (med. tent is 2nd from left, bottom) 



• Figure 6: Medical Operations' equipment in medical tent 
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Equipment 

Medical Equipment 

The following is a listing of equipment that was taken to the Strong Angel work site: 

■ Datex-Ohmeda CS/3 Critical Care Monitor 

■ Siemens SC7000 Critical Care Monitor 

■ SpaceLabs Ultraview 1050 Critical Care Monitor 

■ Compaq Deskpro - Datex-Ohmeda Central Station 
Pentium III 450 MHz, 15in. SVGA monitor 

■ Panasonic Toughbook Ruggedized Laptop - Siemens and Spacelabs gateway 
Pentium II 300MHz, WinNT, 12.1 SVGA Touchscreen Monitor 

■ BioTek Physiologic Simulators 

• LionHeart 3 - multi-parameter simulator 

• Index 2 - pulse oximetry simulator 

• BP-PUMP - non-invasive blood pressure simulator 

■ IBM Thinkpad 740 Laptop - Simulator Control Computer 
Pentium, 100MHz, Win95, 10.1 Flatpanel Monitor 


Support Equipment in Hawaii 

As part of the preparation for the Strong Angel exercise, additional support equipment 
items were anticipated and subsequently ordered or manufactured. This included 
essentials such as hand tools, duct tape, rope, flashlights, and batteries. In addition, some 
other not-so-obvious, but just as essential, items used for this project are listed below: 

• Tarpaulin - used to cover the equipment when not in use. Eliminated need to repack 
the equipment in crates after each session and kept most of the volcanic dust off the 
equipment. 

• Workbench - a wooden surface of approximately 2x6 feet placed on top of two 
shipping containers (assembly required). A simple but very effective asset. 

• Desk lamp - the lighting in the medical tent consisted of two 40-watt incandescent 
bulbs, hardly adequate for equipment setup and note taking. 

• Portable vacuum - an item that seemed unnecessary when packed but was used 
extensively in the test tent by CCCDP engineers and others. 

• Goggles, dust masks, plastic wrap - these items were needed to keep dust off the 
operators and equipment. These items helped, but the dust was so fine there was no 
way to completely block it. 
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Primary Receiving Station 

The following describes the workstation/network utilized at the primary receiving 
station: 

Location: 

Computer Specifications: 

Operating System: 

Network Connection: 

Software: 


Secondary Receiving Stations 

The following describes the workstation/network utilized at the secondary receiving 
stations: 


Johnson Space Center, Building T585, Houston, TX 
Pentium II 350 MHz, 21 -inch color monitor 
Windows 95 

JSC internal network via a lObaseT connection 
Microsoft Internet Explorer 5.0 
Siemens WinView 


Location: 

Computer Specifications: 
Operating System: 
Network Connection: 
Software: 


Star City, Russia 

Pentium II, 300 MHz, Dell Inspiron 7000 laptop 
Windows 98 
T1 connection 

Microsoft Internet Explorer 5.0 


Location: 

Computer Specifications: 
Operating System: 
Network Connection: 
Software: 


Toronto, Canada 

Pentium II, 466 MHz, color monitor 
Windows 98 

Bell High Speed dial-up 50-60 kbs to ISP/public Internet 
Microsoft Internet Explorer 5.0 


Location: 

Computer Specifications: 
Operating System: 
Network Connection: 
Software: 


Philadelphia, PA 

Pentium II, 266 MHz, 17-inch color monitor 
Windows 2000 Server 
608/128 kbs DSL to ISP/public Internet 
Microsoft Internet Explorer 5.0 


Session Communications 

The nominal network connection to the mainland was provided by a direct satellite link 
between the refugee camp and ECU. This was supposed to be available by Sunday June 11, 
but due to technical issues was not available until Tuesday afternoon. The original satellite 
dish was too small to provide the necessary signal gain for the large distances involved. A 
larger dish was eventually located and installed at the refugee site. ECU personnel attempted 
to use the wireless LAN connection to the CMOC until the satellite connection was 
operational, but weather conditions made this an unreliable link. As a result MOB activities 
were condensed to three sessions instead of five. 
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During the three sessions, Microsoft NetMeeting (providing voice over the Internet) and a cell 
phone were used to communicate between the operators in Hawaii and the primary receiving 
station in Houston, Texas. The cell phone connection was used to coordinate session initiation 
and termination and then on an as needed basis during the session. The phone was not used 
through the whole session because of the cost of doing so and the limited battery life of the 
phone. In addition the cell phone connection in Hawaii was unreliable and was dependent on 
the user’s location in the tent and direction the user was facing. This factor also compromised 
the ability to receive calls with the cell phone. 
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The NetMeeting audio connection worked reasonably well, but due to multiple people and 
ambient noise at both ends, using the computer speakers for audio output was not ideal. 
Headsets would have provided for more effective communication. The NetMeeting audio was 
used in Hawaii mainly to listen to the medical scenarios described in Houston. Although AP 
personnel were able to consistently make a NetMeeting connection, the audio connection was 
intermittent. The most reliable communication tool was the NetMeeting Chat window, which 
provided real-time text messaging. This was used throughout all three sessions. 


Session Logistics 

The U.S. Navy provided 120 VAC power to the exercise site. ECU provided the TCP/IP RJ45 
network drop for data communications (this consisted of a Telemedicine Cube from Medweb). 
The data communications network consisted of a bi-directional IMb/s TDRSS satellite link 
between Hawaii and ECU. The satellite connection was then connected to the ECU network 
and made available to JSC via a standard Internet connection. AP personnel were scheduled 
for communications during the off hours, midnight to 4AM (Hawaii time) 12-16 June, but the 
communications system was not fully functional until late Tuesday afternoon (13 June). As a 
result of the lost communication time, access time was rescheduled for all experiments. 
CCCDP was rescheduled to three sessions for a total of 13 hours of satellite time. 

The session times (Hawaii time) were as follows: 

Wednesday 14 June 0000-0500 

Wednesday 14 June 1500-1900 

Thursday 15 June 0100-0500 

For each session, the simulators were connected to each monitor and multiple medical 
scenarios were conducted for each monitor. Flight surgeons, biomedical engineers, and others 
monitored physiologic signals remotely at the Johnson Space Center (JSC) (Bldg. T-585, 
Houston, TX), the Canadian Space Agency (Toronto, Canada), and the Gagarin Cosmonaut 
Training Center (Star City, Russia). Data collection focused primarily on usability and human 
factors. Data were collected from each remote physician using an evaluation form to rate the 
interface, quality of the data, ease of use, and overall ability to remotely monitor a patient. A 
log was kept to catalog problems that arose during deployment and data were collected on 
videotape for analysis of data integrity. (See Appendix C for Communications Diagram) 


SA AAR, 24 



Medical Simulations 

The three critical care monitors were tested using three simulations: Conduction blocks, 
Dropping blood oxygen saturation, and Swan-ganz catheterization. To vary the reviewer’s 
experience, three different space medicine case histories/scenarios were created for each 
simulation giving a total of nine scenarios. These simulations are described in Appendix D. 

In order to evaluate the clinical utility of the monitors under evaluation when used in a remote 
monitoring context, a series of medical case histories/scenarios were developed. Scenarios 
were designed based on risk data relevant to space operations 2 . Each scenario followed the 
clinical presentations and time course case presentations drawn from published literature with 
analogous injury mechanisms and clinical pathology. Flight surgeons were asked to monitor 
the presenting patient via the remote web browser interface. The simulation moderator stated 
the clinical presentation and history to the evaluating clinician who also had a copy of the case 
presentation for reference during the exercise. Following this, the simulation program was 
initiated in Hawaii and the case progressed as outlined in the flow diagrams below. Evaluating 
physicians monitored the clinical course of the patient and were instructed to comment when a 
physiologic parameter changed. Once the evaluator noted a changed, the moderator presented 
additional clinical data and/or asked for what instructions or information requests should be 
sent to the crew to manage the given situation. During the scenarios, the moderator in 
communication with personnel in Hawaii was able to change the flow of the case based on the 
intervention of the evaluating physician. At the conclusion of each scenario the evaluating 
physician was asked what recommendation should be made to the flight control team 
regarding the impact of the medical emergency on the mission. 

In addition to their value in the evaluation of the critical care monitors, the scenarios were a 
first attempt by CCCDP to develop a simulation tool that could be used to test and evaluate 
space medical care capability. Simulations of this sort provide an opportunity to evaluate and 
identify deficiencies in the medical care infrastructure, clinical procedures for the crew/flight 
surgeon/biomedical engineer, equipment testing, and communications. In addition, they 
provide an effective, low cost training or certification tool that, given the remote access 
capability demonstrated, can be used anywhere or at any time. The array of simulators 
selected for this project allow for simulations to be run on the actual equipment operating in a 
standard configuration provide an opportunity to evaluate and validate both the equipment and 
user under operational conditions. 


i 

! 

I 2 

Billica RD, et al. Perception of the medical risk of spaceflight. Aviat Space Environ Med 1996; 67:467-73 
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Evaluations from Simulation Participants 

The simulation participants consisted of flight surgeons, medical trainers, and biomedical 
engineers. Although the reviewers were not able to compare all three monitors together, some 
general conclusions can be drawn from the evaluation forms each reviewer was asked to 
submit. The evaluation form is included as Appendix E. 

• 9 of 1 0 reviewers were confident using this technology to manage a patient. One reviewer 
did not respond. 

• Training is major issue. Several reviewers were not sure that non-medical users would be 
able to set up all the sensors to receive reliable data. In addition, there were some 
concerns that a non-medical user might get “information overload” using these types of 
monitors. 

• 8 of 10 reviewers felt that this type of technology should be used for low earth orbit 
missions. One reviewer was not sure, and one reviewer did not answer. 

• Several reviewers commented that the most useful features of the monitors were clear 
graphical presentation of waveforms. Several recommended enlarging and/or changing 
the font color of the numerical parameters for better readability. 

• Several reviewers commented on the usefulness of the medical simulations in general. 

The scenarios included the number of crewmembers, types of return vehicles and landing 
opportunities, all of which greatly affected the flight surgeons’ decisions on treatment and 
patient management. These types of physiologic simulators may be incorporated into 
future space training simulations. 

Because of time constraints, reviewers were unable to fill out the evaluation forms in their 
entirety; therefore significant aspects of the critical care monitors have not yet been evaluated. 
This particularly refers to questions concerning the system capabilities (numerical and 
graphical trending, data storage, etc.). Little or no time was available for reviewers to access 
these capabilities and to experiment with the monitors themselves. In addition to evaluating 
critical care monitors, the simulation capabilities were identified as a potential training tool 
that could be useful in the future. Although the simulators were not designed to simulate 
medical scenarios, this appears to be a promising application. 

Equipment Performance 

In the field, all monitors and simulators performed exceptionally well given the extreme 
conditions and no anomalies were encountered with any of the monitors. Since the tent was 
not well illuminated, the monitor displays were very easily viewed. Additional observations 
on deployment and implementation are given below: 

• Entanglement of the cables and tubing of the monitors was prevented by using Velcro 
tie-wraps. 

• End tidal carbon dioxide (EtC02> simulation was provided by the monitor operators in 
Hawaii. This proved cumbersome for one person to oversee the computer and provide 
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breaths to match the respiration rate provided by the LionHeart 3 at the same time. It 
is desirable to develop and fabricate an EtC02 simulator. 

• The ST (referring to a segment of the ECG wave) elevation rhythm did not work in 
some of the earlier simulations due to a programming error. This was corrected prior 
to leaving Hawaii. 

• The simulation program was written somewhat modularly, with 2-minute pauses at the 
end of each medical scenario. These pauses should be removed to allow the operator 
to change rhythms sooner if desired. Several times during the simulations, the 
instructor (on the JSC end) wanted to convert a rhythm or go to pacing but had to wait 
for the programmed 2 minutes to pass before proceeding. 

• Communication between the instructor (JSC) and operator (Hawaii) is essential. Voice 
communication over the PC speakers was less than adequate, especially if the 
instructor was not facing the microphone. Chat over NetMeeting worked well but it 
required a second person on the JSC end to transmit orders from the instructor. Two- 
way headsets would probably work best. 

Due to time constraints of reviewers and communication links, none of the reviewers were 
able to evaluate all of the three monitors. In addition, all of the features of the monitors were 
not tested due to the compressed schedule. However, all of the reviewers seemed satisfied 
with the information that they received during their simulations and were able to make 
medical decisions based on this information. Time will be scheduled for a more in-depth 
evaluation of the monitors and their features. 

SpaceLabs Ultraview 1050: 

This critical care monitor performed nominally. The only software needed was Internet 
Explorer 5.0 and the data streams were continuous to the viewer. On occasion, one or all 
data streams would disappear for a few seconds and then reappear. No user intervention 
was necessary. Because this was the only monitor that did not require additional software, 
only this monitor was tested at the secondary locations. The data were successfully 
accessed from Canada, Russia, and Philadelphia in addition to the primary receiving 
station in Houston. This demonstrated the capability of accessing data by a flight surgeon 
at Mission Control, and an International Partner or medical specialist at the same time. 

Datex-Ohmeda CS3: 

This critical care monitor was not able to use the web browser to view the data. The 
company logo and background of the monitor application were visible but no data streams 
were received. The connection was tried on several days with no success. An alternate 
solution was reached: a NetMeeting connection was established from the gateway 
computer in Hawaii to the primary receiving station in Houston. Using the NetMeeting 
Desktop sharing function, the primary receiving station was allowed to view what was on 
the gateway desktop. This allowed the primary station to receive streaming data; however, 
the data streams were choppy, most likely due to sampling rate issues. Although the 
NetMeeting connection was not nominal, the data received were sufficient for the flight 
surgeons to make medical decisions. 
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Siemens SC7000: 


This critical care monitor performed nominally. Proprietary software was loaded on the 
receiving station to view the data; therefore, this monitor was only tested at the primary 
receiving station in Houston. The data streams were continuous to the viewer and there 
were only a few instances when the data streams were lost. 
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Conclusion 


The deployment phase was a great success with all objectives being met. Three out of the five 
critical care monitors received were deployed to Hawaii and setup at the refugee campsite. 

The monitors themselves operated very satisfactorily at the refugee camp despite the 
horrendous operating conditions. All three monitors were connected to a data network that 
ultimately linked the refugee camp to Johnson Space Center (JSC) via satellite and the 
commercial Internet. Consultants at JSC and other sites were able to successfully view the 
medical data and use it to prescribe treatment during the simulated medical scenarios. 

These simulations provided a realistic telemedicine link. There were both hardware and 
communications problems with data occasionally dropping out and requiring real-time 
solutions. It was noted that on some occasions, when the Internet was very congested and 
bandwidth was at a premium, that Internet Explorer would not work in displaying the data at 
the consultant sites. Instead, Microsoft Netmeeting was used to share the desktop of a 
computer displaying the data at the refugee camp with the consultant’s workstation. 

Medical scenarios used in this evaluation provided an effective way to evaluate the critical 
care monitors as well as the feasibility of treating an astronaut aboard the ISS. These 
scenarios allowed NASA flight surgeons to test current space medical procedures using only 
the medical supplies and equipment that are currently scheduled to be on-board the ISS. This 
highlighted the strengths and weaknesses of the current ISS crew health care system. 

Overall, this exercise has been successful and commences the process of enhancing the 
advanced life support capabilities on the ISS. 


I 
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Lessons Learned 


This exercise has proven to be very beneficial and has provided Medical Operations with 

much data as well as many lessons learned. The lessons learned have been categorized into 

three areas, hardware, logistical, and clinical and operational. They are summarized below: 

Hardware 

• The physiological simulators were not designed for this application, but still performed 
adequately. Certain design changes could broaden the use of these devices in training 
medical personnel for ISS and other medical scenarios. This should be explored more 
thoroughly with the equipment manufacturer. 

• A more reliable audio communication method was needed the cell phone used was 
intermittent and at the refugee site calls could only be made from Hawaii - not received. 
GTE Wireless was chosen since they had service available (analog) throughout the big 
island of Hawaii. 

• Voice-over-Internet, via Netmeeting, worked after Internet connectivity was established, 
but it was at times it was difficult to hear over background noise in the tent. It would be 
better to use headphones fitted with a headset rather than use the speaker that was internal 
to the computer. 

• More time should have been spent on evaluating the critical care monitors remote displays. 
There may have been sufficient time if things had gone as planned and the number of 
sessions hadn’t been cut from five to three. 

• Of the monitors evaluated, the Spacelabs monitor was the best in terms of transmission 
over TCP/IP. 

• Datex-Ohmeda and Spacelabs were the most cooperative vendors in terms of working with 
us to provide the equipment and support needed. 

Logistical 

• Acquire as much information as possible on field conditions prior to travel. Because this 
was a military operation and the information was being filtered through a second party 
(CRNC and ECU), we were not quite prepared for the dusty conditions. Knowledge of 
this beforehand would have allowed us to prepare the equipment for these conditions 
before shipment. 

• It would have been better to stay at the refugee camp between sessions instead of traveling 
back and forth from the hotel to the camp. This would have avoided the hassles of 
transporting between the refugee camp and CMOC. 

Clinical and Operational 

• It is important for flight surgeons to be very familiar with CHeCS medications and 
equipment in order to facilitate a rapid response to medical contingencies. 
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• Realization that the current emergency evacuation vehicle, the Soyuz, does not support 
many of the ALS CHeCS components, and due to its small size, make many procedures 
difficult if not impossible to perform. 

• Heavy reliance on critical care monitor data to make diagnostic and treatment decisions 
necessitates a full understanding of how the monitoring equipment works. 

• Patient management via a non-physician crew medical officer (CMO) presents potential 
difficulties and delays in carrying out routine procedures especially if the CMO is the 
patient. 

• These simulations displayed how challenging patient management is using limited 
personnel (i.e. 3 member crew - 1 patient, 1 CMO, one pilot). 

• There are apparent discrepancies between terrestrial and space medical diagnostic and 
treatment approaches. 

• The flight surgeons, when directing the administration of medications, must have an 
awareness of the limited quantities and how these quantities are being used. It may be 
necessary to ration these medications during an emergency to ensure there will be enough 
to last until the patient is returned to Earth. It would be beneficial to maintain a detailed 
inventory of used drugs. 

• The possible loss of communication between the MCC and ISS during a medical 
contingency must be planned for and accommodated. There may only be limited windows 
of opportunity for data exchange. The flight surgeon should always be thinking ahead as 
to what problems might unfold especially if communication is lost. 

• Conducting the medical simulations with the critical care monitors illustrated the fact that 
there is a number of factors influencing medical decisions, including the severity of a 
medical problem, the abundance of primary landing site (PLS) and emergency landing site 
(ELS) opportunities, and critical time of illness. 

• Additional simulations should be performed to refine protocols for patient management 
both during and after a code. 

• The real-time critical care monitor data will be invaluable in managing a remote critically 
injured patient. 


Follow-on Activities 


• Continue to follow-up with vendors and pursue other vendors for participation in this 
ongoing evaluation. 

• Complete in-depth evaluation of each critical care monitor received. This will include: 

1 . Operational testing - power usage, battery life, etc. To be completed August 2000. 

2. Evaluation of human factors - man-machine interface. A usability test will be 
performed on all monitors beginning July 2000 and continuing through September 
2000, depending on availability of monitors. The usability test plan is included as 
Appendix F. 

3. Evaluation of clinical capabilities. This may take the form of a side-by-side 
comparison matrix. 

• Testing of remote monitoring capabilities for each critical care monitor including 
operational testing, human factors, and clinical functionality at the remote site. 

• Side by side comparison of all critical monitors reviewed by flight surgeons, trainers, and 
biomedical engineers. Two-day workshop tentatively scheduled for September 2000. 
Multiple flight surgeons and external reviewers will be invited, as well as vendor 
representatives. 

• Analyze the evaluations done during the simulations in Hawaii and determine a general 
consensus. 

• Define space critical care monitoring needs, define discrepancies between state-of-the-art 
equipment and NASA’s needs, summarize the state-of-the-art in critical care monitors, and 
develop a white paper to document these results. 

• Final recommendation/specifications for space medicine critical care monitoring. 
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Appendix A - List of URLs 


The following websites will provide additional information on the exercise: 

Strong Angel specific websites 

• Strong Angel briefing 

http://www.Quasar.org/memes/intellimedcom/RIMPAC2000-Strong-Angel-brief.htm 

• Strong Angel website 
http://www.strongangel.org/ 

• RIMPAC website 

http://www.cpf.navv.mil/rimpac2000/index.htm 

Medical equipment vendors websites 

• Spacelabs Medical Systems, Inc. website 
http://www.slmd.com 

• Datex-Ohmeda website 

http://www.datex-ohmeda.com/products/monitoring cccm.htm 

• Siemens Medical website 

http://www.med.siemens.com/medroot/en/prod/diag/elec/index.html 

• Agilent Technologies 

http://www.healthcare.agilent.com/patient monitoring/cgi- 

bin/show product.pl?M3%20and%20M4%20Series%20Patient%20Monitors 

• GE/Marquette 

http://www.gemedicalsvstems.com/medical/index.html 

• Datascope, Corp. 
http://www.datascope.com/ 

• Critikon, Co. 
http://www.critikon.com/ 

• Protocol Systems, Inc. 
http://www.protocol.com/ 

• Biotek Instruments website 
http://www.biotek.com/ 

Other websites 

• Medweb website 
http://www.medweb.net/ 

• MDB Information Network 
http://www.mdbinfonet.com/ 
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Appendix B - Critical Care Monitor Requirements 


1 . Power: 

a. The system shall be able to be powered from either 1 10VAC at 60Hz or 220V AC 
at 50Hz. 

b. The system shall have a battery back-up capability. This capability shall be 
integral to the systems’ design and should allow the monitor to operate for 30 or 
more minutes under most monitoring situations. 

c. The battery should recharge by connecting the monitoring system to an external 
power source and should not require battery removal. 

2. Physical: 

a. The system should be portable and able to withstand a field/transport environment. 

b. The system should weigh no more than 30 pounds, and the physical volume should 
be no greater than 1 cubic foot. 

3. Data: 

a. The system should have the capability to connect to a 10-BaseT Ethernet network. 

b. The system should transfer medical data real time via IP. 

4. Medical Monitoring: 

a. The system shall be able to acquire a 5-lead electrocardiogram (ECG) at a 
minimum. 

b. The system should be able to monitor SpC> 2 . 

c. The system shall be able to monitor non-invasive blood pressure. 

d. The system shall be able to monitor invasive blood pressure. 

e. The system shall be able to monitor body temperature. 

f. The system shall be able to monitor ETCO 2 . 
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Appendix D - Medical Simulations 


A session administrator presented the following scenarios to NASA flight surgeons. After the 
flight surgeons were presented a case they were shown, on a consultant workstation, real-time 
data streaming from a critical care monitor in Hawaii. They were then told to manage the 
patient using only supplies on-board the ISS. The monitor in Hawaii was connected to patient 
simulators that were programmed to vary the parameters in a manner that was consistent with 
the patient’s condition. There was two way interaction between the flight surgeons and the 
session administrator. The session administrator was in contact with personnel in Hawaii and 
directed them when to vary the parameters by initiating certain programs. 




Simulation 1 - Cardiac Arrhythmia Conduction blocks 

Monitor display sequence 












Corresponding Case Histories/scenarios 
Case A 

50 y/o female pre extra-vehicular activity (EVA). Complains of light-headedness and 
palpitations after working long hours to repair CO 2 scrubbers. Patient has no history of 
cardiac problems. Risk factor (RF) positive for family history with father having MI at 
60 years and slightly raised LDL cholesterol and reduced HDL cholesterol. Has felt 
tired over last 7 days. Total time on ISS 60 days. No other medical or psychological 
issues being worked. 

Vitals as per monitor. Patient looking anxious and concerned. Plan? 

Case B 

45 y/o male astronaut who presents to an unscheduled private medical conference 
(PMC) with serious concerns about palpitations and chest pressure after exertion on 
the treadmill 10 minutes ago. The shuttle has been docked to the ISS for 6 days and 
this is his first mission. He confesses this has happened before and was seen privately 
by a cardiologist in the booming community of Nowhere, Montana. The astronaut was 
reassured at that time that the findings on a 24-hour holter monitor were only 
significant for five runs of 3 to 4 beat wide complex tachycardia. The cardiologist 
reported it to be supraventricular tachycardia (SVT) with aberrancy. The astronaut did 
not inform the Flight Medicine Clinic (FMC) of these findings, since he was told it 
was not serious and that reporting it would ground him. He is very concerned now 
because the discomfort has not abated after exercise. The patient had a 220-msec first 
degree block, which was wavered by the Aerospace Medicine Board (AMB) because 
of the 10-year history of the finding. The patient notices palpitations when he has 
alcohol or consumed large amounts of caffeine. The patient recalls one episode of 
syncope where he woke up on the floor of the bathroom early in the morning with a 
laceration on his chin where he hit the sink, probably during the fall. He never 
reported the incident. The patient has a history of avoiding yearly exams and has 
refused to participate in investigations that monitor ECG. Positive family history for 
MI in mother age 55 and grandmother MI 60, with hypercholesterolemia. 

Patient has complaints of chest pain radiating into the left-arm and dyspnea. The pain 
radiates to the neck. The patient complains of extreme nausea. 

Vitals as per monitor. Plan? 

Case C 

55 y/o male astronaut is on the end of the P6 truss when he becomes giddy, confused 
and eventually nonresponsive. The patient is dragged back to the airlock, repressed 
and the helmet is doffed. The following vitals are measured on the patient, (vitals are 
given by session administrator) 

The suit is eventually completely doffed and the patient is transported back to the Lab 
module. Vitals as per monitor. 

Paced rhythm. The next primary landing site (PLS) is three hours away. Plan? 
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Simulation 2 - Dropping Blood Oxygen Saturation 


Monitor display sequence 



Corresponding Case Histories! scenarios 

Case A 

55 y/o male astronaut post second EVA in 3 days to repair gyrodynes. In the middle of 
the sleep period he is awoken with chest discomfort and shortness of breath. Has 
noticed some pressure in the chest with no radiating pain. Pain is not pleuritic in 
nature. Has some reflux symptoms when asked specifically and has noticed them on 
several other flights, but this is different. States he has been having trouble breathing 
and is obviously shortness of breath (SOB). Patient is working to breathe and finds it 
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easier to breathe when he grabs the rack and braces his feet... something like a 
microgravity semi-Fowlers position. Crew medical officer (CMO) can hear breath 
sounds in both lungs. 

What is your differential? Vitals as per monitor. 

On O 2 patient begins to become confused and complains of feeling weak. Patient has 
signs of left-sided hemiparesis with reduced strength as per decompression sickness 
(DCS) patient. Patient is not oriented to person, place, or time. Breathing effort 
reduced. 

The commander notices the O 2 line on the mask leaking (cabin noise prevents crew 
from hearing leak). Plan? 

Case B 

47 y/o veteran astronaut intravehicular activity (IV A) crew member notices an intense 
irritation of the eyes when the airlock door is opened to help the two extravehicular 
activity (EVA) crew members who have recently ingressed from a 6-hour EVA. The 
IVA crew member advises the rest of the crew to don quick-don masks (QDM) and for 
the EVA crew members to stay on the services and cooling umbilical (SCU). The 
patient goes on QDM but notices a cough and irritation that prevents him from 
speaking in complete sentences. The other 3 crew members are now helping the 
disabled crew member. The EVA crew members return to the airlock and close the 
hatch. The patient is taken to the lab module and the hatch is closed to the node on the 
Russian and American side, effectively isolating the airlock. Drager tubes are used by 
the EVA members and found to be positive for nitrogen tetroxide. 

Patient is stable for 20 to 30 minutes but now is complaining of shortness of breath 
(SOB) and pleuritic chest pain. The communications at this time is poor due to 
TDRSS communication interruptions. The crew medical officer (CMO) is concerned 
that we just missed the last primary landing site (PLS) opportunity and the next one is 
not for 24 hours in Russia. The shuttle is not present. The transport vehicle is the 
Soyuz. The Assured Crew Return Vehicle (ACRV) has been delayed due to budget 
and technical problems. 

Oxygen, intubate, physical exam, start IV. 

Physical exam is visualized more clearly using the Medical Operations virtual private 
network (VPN) videoconferencing system. The patient has intercostal indrawing, 
accessory muscle use with tracheal tug and has a visible pulses of 15 to 20 on the 
monitor. Auscultation using a digital stethoscope reveals diffuse inspiratory and 
expiratory wheezes with a prolonged expiratory phase. A new X-ray on the ISS shows 
the following (findings described by the session administrator). The patient has 
removed the QDM and is now on 5 L/min 100% oxygen by non-rebreather. O 2 sat is 
97%, heart rate (HR) is 105. respiratory rate (RR) is 18. 
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The patient continues to maintain his airway and ventilation rate. The EVA crew 
members are venting the airlock and the Flight Dynamics (FD) instructs the crew to 
configure the ISS for autonomous Ops. and to power up both Soyuz spacecrafts. The 
EVA crew is still on SCU and one crew member is performing air sampling 
procedures from the Node 1 hatch. FD is preparing to vent the Node so the crew can 
power up the Soyuz on the Russian side after repress. The CMO only has one assistant 
since the commander needs to safe the ISS. 

The patient is deteriorating and x-ray 12 hours later (10 hours before the next PLS) 
shows the following (session administrator presents data). O 2 sat is deteriorating and 
the patient is now on 100% at 10 L/min. The patient is showing signs of reduced level 
of consciousness (LOC) and the respiratory rate has decreased to 14/min. Patient is 
very light-headed and confused. 

Vitals as per monitor. Intubate? With Soyuz coming up? Plan? 

Case C 

A 52 y/o astronaut ISS increment candidate has been brought out of the Hydrolab tank 
at Star City after a 6-hour run in the Orlan spacesuit. The patient starts to complain of 
chest pain and SOB. The patient further complains of knee pain and the flight surgeon 
notices a rash over the patient’s back. He collapses 30 minutes after doffing his suit. 
The patient is connected to a patient monitor and the data presented here at MCC-H. 
The Star City flight surgeon is at the Black Sea supporting crew survival training. 

Vitals as per monitor. Plan? 
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Simulation 3 - Swan-Ganz catheterization 


Monitor display sequence 



Corresponding Case Histories/ scenarios 

Case A 

45 y/o physician astronaut is intubated and invasively monitored after having a Mars 
Ford Grand Navigator fall on her, crushing her left leg. Patient suffered pulmonary fat 
emboli, which put the patient into acute right ventricular failure. Patient was stabilized 
using advanced trauma and life support (ATLS) procedures and subsequently 
surgerized by Dr. Mark Campbell Jr., the other Mars mission physician who amputated 
the crushed limb. Patient is stable on inotropic support of Dopamine. 

Patient is in the 1/3 gravity intensive care unit (ICU) on Mars with a 4-minute delay in 
data feed. Patient is being managed by Dr. Campbell and wishes to have the flight 
surgeon, Dr. (insert name), on call to follow the insertion of the right pulmonary 
catheter and help determine the wedge pressure. Dr. (insert name) has requested that 
you follow this procedure from your computer at home. It is 4 AM in the morning 
Earth time and you have just been awakened by the phone. You are covering for Dr. 
Green who is out of town for 2 days. 
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Is the catheter proceeding correctly? Dr. Campbell has concerns about the transducer 
zero... are these pressures okay for 1/3 gravity? Should the patient be given more 

fluids given the cardiac index is (value given by session administrator). Dr. 

Campbell wants to know if the Earth cardiac index normals the same as on l/3g? 

Vitals as per monitor. Please advise. 

Case B 

A new station is on the moon with 20 crew members. A 35 y/o patient has been 
admitted to the intensive care unit (ICU) for treatment of an episode of acute 
pneumonia secondary to aspiration. The patient experienced an episode of nausea and 
vomiting during an extravehicular activity (EVA) and aspirated in the suit. The patient 
was brought back to base one hour later and the lunar extravehicular mobility unit 
(EMU) was doffed. The lunar base is pressurized at 5 psi at 100% oxygen. The 
patient deteriorated and was intubated and placed on a positive end-expiratory pressure 
(PEEP) of 20 and rate of 18 with inverse ration SIMV. A central line was placed and a 
Swan floated. You are asked to help watch the wedge pressure. Is the wedge pressure 
appropriate for 1/6 g and an atmosphere of 5 psi of 100% 02? 


Vitals as per monitor. Plan? 




Form 1 

Strong Angel Exercise Evaluation 

Date: Reviewer: 

Medical Specialty: Monitor: 


Background Information: 


1 . Have you used critical care monitors before? 


Yes 

No 

If yes, when was the last time you used this technology? 

Days 

Weeks 

Years 

If yes, how many patients have you assessed? 

Many 

Some 

None 

If yes, for what purpose were the monitors used? (i.e. ICU, diagnosis, management) 

2. Have you used this monitor (manufacturer/model) before? 


Yes 

No 

3. Have you ever diagnosed or treated patients long-distance? 


Yes 

No 

4. Have you ever supported a space mission as a flight surgeon? 

Yes 

No 


Performance: 


1. Please rate the following technological performance qualities of the primary interface screen: 



Simple 

5 

4 

3 

2 

1 

Complex 


High Tech. 

5 

4 

3 

2 

1 

Low Tech. 


Safe 

5 

4 

3 

2 

1 

Unsafe 


Accurate 

5 

4 

3 

2 

1 

Inaccurate 


Reliable 

5 

4 

3 

2 

1 

Unreliable 


Easy to use 

5 

4 

3 

2 

1 

Difficult to use 


Durable 

5 

4 

3 

2 

1 

Fragile 


Attractive 

5 

4 

3 

2 

I 

Unattractive 


High Quality 

5 

4 

3 

2 

1 

Low Quality 


Hike 

5 

4 

3 

2 

1 

I dislike 


2. Please rate the following system capabilities ( 5-Excellent, 1-Poor): 





Numerical Trending 


5 

4 

3 

2 

1 

N/A 

Graphical Trending 


5 

4 

3 

2 

1 

N/A 

Data Storage 


5 

4 

3 

2 

1 

N/A 

Alarms 


5 

4 

3 

2 

1 

N/A 

Calculated Parameters 


5 

4 

3 

2 

1 

N/A 
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13. Were you able to confidently assess the patient using the data on the monitor screen? 


Yes 


No 



4. Were you able to confidently manage the patient using the data on the monitor screen? 

Yes 

No 

5. Was this technology helpful in mitigating the risks of the patient? 

Yes 

No 


Usability: 

Agree 



Disagree 

1. Overall, I found this monitor easy to use. 

4 

3 

2 

1 

2. I was able to view the screen comfortably. 

4 

3 

2 

1 

3. The waveform data were presented effectively on the screen. 

4 

3 

2 


4. The numerical data on the screen were easy to read. 

4 

3 

2 


5. I was able to access the system capabilities 
effectively, (i.e. trending, graphing) 

4 

3 

2 

i 


Comments: 


1 . Would you be confident using this technology to manage a remote patient? Yes No 


Why or why not? 


2. From a clinical, operational, and ethical standpoint, would you Yes No 

recommend using critical care monitors in Low Earth Orbit? 

Why or why not? 


3. How did using this technology affect your ability to effectively manage your patient? 


|4. What were the most useful features on this monitor? 


5. If you could change any aspect of this monitor, what would it/they be? 
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1 6. I found the following aspects of this monitor particularly difficult to use: 


7. a) Do you feel that non-clinical care providers could use this interface? 


7. b) What modifications would you recommend be made to support use by non-clinical professionals? 


8. Would you feel comfortable changing the monitor configuration at the screen interface? 
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Form 2 


(The reviewers that were able to evaluate more than one monitor were also asked to submit this evaluation form) 


Strong Angel Comparison Evaluation 

Date: Reviewer: 


1. Of the [two or] three critical care monitors (Siemens, Datex-Ohmeda, and SpaceLabs) that you have interfaced with, 
which did you like the most and why? Please be specific. 


2. Of the [two or] three critical care monitors (Siemens, Datex-Ohmeda, and SpaceLabs) that you have interfaced with, 
which did you not like and why ? Please be specific. 
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Appendix F- Critical Care Monitor Usability Test Plan 


(Usability Test Plan for Critical Care Monitors in support of Strong Angel Project) 


Purpose 

The main purpose of this test is to evaluate and compare subjective usability/human factors of 
the various monitors used in the Strong Angel project. This test fits into the overall evaluation 
of the state-of-the-art in critical care monitors as documented in the Strong Angel project plan 
(April 2000). The test will measure the time it takes to complete various tasks that might be 
performed on ISS using each of the monitors. 

Test Objectives 

The specific objectives of the test are: 

1 . Determine which method of user interface (com. wheel vs. touch screen) is preferable 
to most participants. 

2. Determine which monitor(s) takes the least amount of time for participants to complete 
a given task. 

3. Determine which monitor(s) provides the best viewing angle and readability of data as 
distance from the monitor increases. 

4. Determine which display format (color, font size, etc.) is preferable to most 
participants. 

Methodology 

At least 5 participants that fit the expected profile will be used in the test, unless more 
personnel are available. Prior to the test, each participant will be asked to fill out a short 
questionnaire to gather background information. Then, the participants will be given a brief 
orientation period with each monitor (not to exceed three minutes for each). The participants 
to be selected will have at least a basic understanding of physiological signals and their 
acquisition so that background information in this area need not be provided. 

The first part of the test will consist of performance measurements. The participants will be 
asked to carry out a series of tasks with each of 7 monitors (depending on availability). 

During the performance test, the time it takes to complete each task will be recorded and any 
difficulty encountered during the test (either through participant error or equipment 
malfunction) will be noted. The monitors will be presented to each participant in a different 
order. Breaks will be taken between each monitor to allow for equipment setup. The 
participant and monitor(s) will be videotaped for later analysis and verification of test results. 
An evaluation the effectiveness of monitor alarms will also be performed during this part of 
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the test. The participant will be instructed at the beginning of the test that alarm conditions 
may occur during the course of the test and when an alarm is sounded, to identify the source as 
quickly as possible. The alarm condition selected will be different for each monitor and will 
fall at varying times during each test sequence. 

In the second part of the test, the participant will be asked to determine the maximum viewing 
angle and distance from the monitor with which they feel comfortable viewing the data. This 
will be accomplished using a string attached to the tabletop directly in front of the monitor. 
The string will be held by the participant and will rotate through angle indicators marked on 
the tabletop as the participant moves from side to side. Once the participant has indicated 
when the viewing angle and distance have reached the limit for clear readability, the angle and 
distance from the monitor will be recorded. Since this test is very dependent on the 
participant’s vision, they will be instructed to wear their glasses or contacts if they normally 
do so. 

Following the test, each participant will be asked to fill out a brief questionnaire that asks 
questions relating to subjective parameters and preferences (display colors, ease of use, button 
labeling, user interface, etc.). 

Task List 


The following tasks are to be performed (in order) for each monitor: 


Task# 

Task Description 

Task Detail 


Power on & discharge patient 

Power on unit and discharge previous patient, erasing 
data. 

Time to complete: 2 minutes 

2 

ECG connections & measurement 


3 

NIBP connections & measurement 



Sp0 2 connections & measurement 

Connect Sp02 cable to monitor and patient and call out 
Sp02 percentage. 

Time to complete: 2 minutes 

5 

Change channel 2 waveform 

Configure monitor to display Respiration waveform on 
Channel 2. 

Time to complete: 5 minutes 


View trend graph (HR & Sp02) 

Configure monitor to display a graph of heart rate and 
Sp02 trend data. 

Time to complete: 4 minutes 

7 

Return to normal screen 

Return monitor to normal monitoring screen. 
Time to complete: 10 seconds 


Test Environment/Equipment 
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The test environment will be in a typical laboratory, with varying amounts of activity taking 
place. It will not be a quiet environment since this would not be expected on-orbit in the event 
that one of these monitors was used. 

The test administrator, in addition to recording data and making notes will also serve as the 
patient for NIBP, Sp02, and ETC02. The test administrator will offer no guidance in the 
completion of tasks. However, the user’s manuals for each monitor will be available for 
reference. 

The monitors to be tested are listed below. All cables and tubing for each monitor will be 
available at the start of the test and the participant must select the proper attachments. 


Monitor 

Manufacturer 

Model 

A 

Datex-Ohmeda 

CS3 

B 

Siemens 

SC7000 

c 

SpaceLabs 

Ultraview 1050 

D 

Datascope 

Passport 

E 

Datascope 

Expert 

F 

Protocol 

Propaq CS 

G 

Protocol 

Propaq 

H 

Hewlett-Packard 

M3 





Evaluation Measures 


The following data will be collected and/or calculated: 

1 . The average time to complete each task for each monitor. 

2. The number of errors encountered during each task and whether the error was due 
to human error, equipment error, or both. 

3. The percentage of participants who finished each task successfully. 

4. The percentage of participants who correctly identified all alarm conditions within 
the allotted time. 

5. The average maximum viewing angle for each monitor. 

6. The average maximum readability distance from each monitor. 

7. Rankings of equipment usability/human factors. 

Test Report 

The results of this test are part of a larger evaluation of critical care monitors. Therefore, the 
usability test results will be reported in the final Strong Angel project report. The final report 
will be completed following Flight Surgeon evaluation. 
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